Multisignature key custody, key customization, and privacy service

ABSTRACT

Users of a multisignature wallet can customize keys to initiate various transactions. As a user specifies roles to customize keys, a smart contract is updated to associate the roles with the keys, where the customized keys are then associated with the user&#39;s multisignature wallet. The user may perform transactions by signing using the key or an address of the key, where a transaction can be processed upon verifying the key and its role. Additionally, a privacy service can facilitate blockchain transactions initiated using a key of a multisignature wallet. The privacy service receives a transaction signed by a key of the multisignature wallet and identifies a proxy wallet using the key. The privacy service validates and signs the transaction, which is then sent to a proxy wallet. The proxy wallet can cause a blockchain transaction to be executed.

CROSS REFERENCE To RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No.63/091,492, filed Oct. 14, 2020, and U.S. Provisional Application No.63/136,124, filed Jan. 11, 2021, which are incorporated by reference intheir entirety.

TECHNICAL FIELD

The disclosure generally relates to the field of blockchains, andspecifically relates to enhanced security of blockchain keys.

BACKGROUND

Multi-signature wallets require multiple signatures from different keysin order to complete a transaction. Typically these keys are allequal—to sign a transaction for completion, where, for example for athree of five multisignature wallet, if three signatures are received,then the transaction will be completed. Users who store their own keyson their own devices, rather than having them managed by a custodyprovider, are responsible on their own to keep the keys secure and safe(e.g., from misuse and/or loss), which may result in unintentional loss.

Additionally, while blockchain transactions are anonymous insofar thattransactions are performed to and from blockchain addresses, which bythemselves do not reveal identities of owners, malicious users may beable to leverage the property of transparency in blockchain transactionsto nonetheless infer certain information about a user. This is becausewhen a transaction is performed by a user, the user's address becomespublic, and information may be derived based on the address (e.g., theuser's balance on that address, past and future incoming and outgoingtransactions, etc.).

BRIEF DESCRIPTION OF DRAWINGS

The disclosed embodiments have other advantages and features which willbe more readily apparent from the detailed description, the appendedclaims, and the accompanying figures (or drawings). A brief introductionof the figures is below.

FIG. 1 illustrates one example configuration of a system environment forcustomization and remote custody of keys, in accordance with anembodiment.

FIG. 2 illustrates one embodiment of elements of a custody provider forgenerating and operating customized keys.

FIG. 3 depicts a multisignature contract where keys are obtained fromtwo or more sources.

FIG. 4 depicts one embodiment of activity corresponding to an approvalkey process when executing a multisignature contract.

FIG. 5 depicts one embodiment of a veto process for canceling executionof a transaction of a multisignature contract.

FIG. 6 illustrates one embodiment of activity of using a recoveryprocess to challenge a key with an end goal of replacing the challengedkey with a different key or removing the challenged key.

FIG. 7 depicts one embodiment of an exemplary process for using aprivacy service and a proxy wallet to execute private transactions.

FIG. 8 depicts an exemplary process for executing a transaction with aproxy wallet using a salted hash.

FIG. 9 depicts an exemplary process for executing a transaction with aproxy wallet using a multiparty computation signature.

FIG. 10 is a flowchart illustrating a process for initiating atransaction using a customized key, in accordance with one embodiment.

FIG. 11 is a flowchart illustrating a process for initiating ablockchain transaction using a privacy service, in accordance with oneembodiment.

FIG. 12 is a flowchart illustrating a process for initiating atransaction using a smart contract, in accordance with one embodiment.

FIG. 13 is a block diagram illustrating components of an example machineable to read instructions from a machine-readable medium and executethem in a processor (or controller).

DETAILED DESCRIPTION

The Figures (FIGS.) and the following description relate to preferredembodiments by way of illustration only. It should be noted that fromthe following discussion, alternative embodiments of the structures andmethods disclosed herein will be readily recognized as viablealternatives that may be employed without departing from the principlesof what is claimed.

Reference will now be made in detail to several embodiments, examples ofwhich are illustrated in the accompanying figures. It is noted thatwherever practicable similar or like reference numbers may be used inthe figures and may indicate similar or like functionality. The figuresdepict embodiments of the disclosed system (or method) for purposes ofillustration only. One skilled in the art will readily recognize fromthe following description that alternative embodiments of the structuresand methods illustrated herein may be employed without departing fromthe principles described herein.

Configuration Overview

One embodiment of a disclosed system, method and computer readablestorage medium is provided herein for enabling customization of keys byusers. A command may be received, by a user interface, to assign a roleto a key or keypair (e.g., public and private keys). Responsive toreceiving the command, an API operably coupled with the user interfacemay transmit an update to a smart contract to associate the role withthe key (e.g., the public key of a keypair), where the key is associatedwith a multisignature wallet (e.g., a wallet that maintains the privatekey of the keypair). The API may receive a request to initiate atransaction, the transaction affected based on whether a key having theassigned role signs the transaction. Responsive to the key having theassigned role signing the transaction, the transaction is affected in amanner. For example, the key may be an approval key that, when signing atransaction initiated by an initiation key, causes the transaction to beexecuted.

In another embodiment of a disclosed system, method and computerreadable storage medium is provided herein for initiating a transactionusing a privacy service. A privacy service receives a blockchaintransaction signed by at least a proxy key of a multisignature wallet(e.g., the blockchain transaction may be signed by initiation, approval,and/or proxy keys of a multisignature wallet). The privacy serviceidentifies a proxy wallet based on the proxy key (e.g., using theaddress of the proxy key). The blockchain transaction is validated(e.g., using one or more addresses corresponding, respectively, to oneor more initiation and/or approval keys) and in response to thevalidation, the privacy service signs the blockchain transaction (e.g.,using a privacy service key). The privacy service forwards the signedblockchain transaction to the proxy wallet. In some embodiments, theproxy wallet is associated with both the proxy key and the privacyservice key, which can be used together to sign the blockchaintransaction. A signature by a key or combination of keys of the proxywallet can cause the blockchain transaction to be executed.

Example System Environment for Customization and Remote Custody of Keys

FIG. 1 illustrates one example configuration of a system environment forcustomization and remote custody of keys, in an accordance with anembodiment. FIG. 1 depicts environment 100, which includes client device110, client device 111, network 120, custody provider 130, blockchain141, multisignature smart contract 140, and privacy service 150. Clientdevice 110 and client device 111 are end-user devices. Client device 110and client device 111 may be devices of a same user or of differentusers. Additional client devices may be present in environment 100. Aclient device may output a user interface for display to a user. Theuser interface may be operable by the user to cause a key to begenerated, to assign a role to a key, and to initiate requests inconnection with smart contract 140. The user interface may be generatedby an application of a multisignature wallet that has an applicationprogramming interface (API) operable to update multisignature smartcontract 140. As referred to herein, the terms “multisignature” and“multisig” may be used interchangeably. The application may be installedon a client device, or may be accessed using a browser (e.g., bynavigating using the browser to a web page provided by a web server thathosts the user interface). Client devices 110 and 111 store private keysthat are generated by those devices.

The user interface enables a user to assign different roles to keys,thus enabling use of those keys to perform different functions (e.g., inconnection with signing a transaction). For example, the user interfacemay include selectable options that, when selected, cause roles to beassigned to keys associated with a user account. Some exemplary rolesinclude a role of being an “initiation key”, an “approval key”, a “vetokey”, and a “recovery key.” The initiation key may perform an initiationfunction, the approval key may perform an approval function, the vetokey may perform a veto function, and a recovery key may perform arecovery function. The user interface enables the user to assign one, orseveral, roles to a single key with respect to a given transaction.Responsive to receiving an assignment of a role to a key, multisig smartcontract 140 is updated to indicate the role of the key with respect tothe affected transaction. Alternatively, once a role is assigned, therole may remain in effect until challenged (e.g., the role is effectivefor multiple transactions until challenged).

The term initiation key, as used herein, may refer to a key that hasbeen assigned an initiation role. Such a key may be used to perform aninitiation function (e.g., to initiate a transaction). For example, aninitiation key may be used to sign a transaction request. Thetransaction may have a requirement that one or more approval keys signthe transaction. The term “approval key,” as used herein, may refer to akey that has been assigned an approval role. An approval key may be usedto perform an approval function (e.g., to sign a transaction in order tovalidate the transaction and cause it to be executed). The term “vetokey” may refer to a key that has been assigned a veto role. A veto keymay be used to perform a veto function (e.g., to cancel a transaction,for example, by signing the transaction within a selected period of timerelative to when an initiation key signed the transaction). The term“recovery key” as used herein may refer to a key that has been assigneda recovery role. A recovery key may be used to perform a recoveryfunction (e.g., to replace keys). For example, the recovery key mayremove a key that was previously assigned a certain role (e.g., aninitiation role or an approval role), and/or assign that role to adifferent key. These roles of keys are described in further detail belowwith respect to FIGS. 4-6. Any other role may be assigned as well and isin the scope of this disclosure.

Network 120 provides a communication infrastructure between clientdevice 110, and blockchain 141 (on which multisig smart contract 140 mayrun, through which multisig smart contract 140 may be communicatedwith). Network 120 also provides a communication infrastructure betweenblockchain 141 and custody provider 130. Network 120 is typically theInternet, but may be any one or more networks, including but not limitedto a Local Area Network (LAN), a Metropolitan Area Network (MAN), a WideArea Network (WAN), a mobile wired or wireless network, a privatenetwork, or a virtual private network.

Custody provider 130 generates private keys and stores those keys in asecure way. Custody provider 130 may additionally house and enforcepolicies associated with keys. Further details of the activity ofcustody provider 130 are described in further detail below with respectto FIG. 2.

Multisig smart contract 140 comprises program code for use with anelectronic distributed ledger. In one embodiment, the electronicdistributed ledger is a blockchain 141. In one embodiment, multisigsmart contract 140 includes rules/logic for validating and/oreffectuating transactions that are stored in blocks of blockchain 141.For example, a user of a client device, such as client device 110, sendsa transaction to blockchain 141 (e.g., signed with needed signaturesfrom private keys held by the user). This may be a simple sendtransaction (e.g., to move crypto currency), or may be a transactionthat triggers a function (e.g., corresponding to a role of a key) insmart contract 140 (which may be, e.g., a multisig smart contract).Smart contract 140 defines rules/logic about how the state of blockchain141 is changed during a transaction (e.g., storing a value in a statevariable).

In some embodiments, smart contract 140 stores addresses attached toroles of keys. For instance, a suitable key generation technique may beused to generate a public-private key pair (e.g., by randomly selectinga private key and generating a public key from the private key). Thepublic address of this key pair may be assigned a certain role. Forexample, the corresponding public key of this key pair may be used toderive a public address. The public address may be registered with smartcontract 140 as having the assigned role. In order to trigger atransaction, smart contract 140 is used to determine whether signaturesthat are needed according to the roles are attached (e.g., it is checkedthat the signatures fit to these addresses assigned to the roles).Further particulars about roles and their corresponding signatures aredescribed in further detail below. However, it should be appreciatedthat aspects of the present disclosure are not limited to storingaddresses. In some embodiments, smart contract 140 may store publickeys, in addition to, or instead of, addresses.

The rights to use a key may change hands or be overruled, which may beupdated in smart contract 140. In an embodiment, a user may have (eitherstored on their client device or within custody provider 130) a specialdapp key, which is a key that can sign on behalf of the user in the dappcontext. Dapp keys are created by and in full control of the user andare assigned to the dapp using technologies like wallet connect or aweb3 injection into the dapp's web side. Dapp keys may be usedconsistent with the manner that keys are discussed below.

Privacy service 150 is a centralized service for providing users accessto a proxy wallet, through which the users' multisig transactions areanonymized. Privacy service 150 is described in further detail belowwith reference to FIGS. 7-9.

FIG. 2 illustrates one embodiment of elements of a custody provider forgenerating and operating customized keys. Custody provider 130 includesvarious stores, such as custody key vault 290, as well as key policydatabase 291. Custody provider 130 also includes key policy module 250.Fewer or aspects may be used by custody provider 130 to perform theactivity disclosed herein; the depicted modules and databases are merelyexemplary tools for performing the disclosed functionality.

Custody key vault 290 may store keys in hot storage, cold storage, orfrozen storage. The term hot storage, as used herein, may refer to anetwork-connected storage where keys stored therein are ready to be usedfor signing after a successful authentication. The term cold storage, asused herein, may refer to storage that is not network-connected,requiring physical access to use stored keys for signature. In anembodiment (e.g., for business processes), cold storage may include keysin an air gapped facility (e.g., no connection at all to the Internet).To use a cold storage key, a manual process involving a mobile device isused to obtain a signature (e.g. a message to be signed is stored at amobile data storage, such as a secured USB flash drive). The mobiledevice is connected to the air gapped system, the signature is generatedand again stored at this device, and then manually moved to a connectedsystem for inclusion of the signature in the transaction. In anembodiment (e.g., personal use), to use a cold storage key, signing mayoccur via insertion of the cold storage into a network-enabled device,such as insertion of a universal serial bus (USB) drive that stores thekey into a personal computer. The term frozen storage, as used herein,may refer to storage that is not network-connected, and that is storedon metal plates with no ready access to network connectivity. A user mayaccess keys in custody key vault 290 after being authenticated throughone or more verification techniques, such as biometrics (e.g., any of avein scanner, fingerprint authentication, an iris scan, facialrecognition, etc.), a password, a memory puzzle, code verification viatext message to the user's client device 110), and the like. A userinterface may be presented at custody provider 130 that operates in asimilar manner to that described with respect to client devices 110 and111.

The custody key vault offers a solution that is technically andarchitecturally secured against unauthorized access and sabotage, andthat all devices are protected against failure and manipulation in aredundant manner. Even with physical access it is not possible to accessthe keys. For example, to establish custody provider 130, severalhigh-security datacenters distributed all over the world may be operatedin different countries. Each of these data centers houses a secure ITinfrastructure, the core of which are Hardware Security Machines (HSM).Keys are stored in these HSMs and cannot leave them under anycircumstances (secure by design). These keys can be used to generatesignatures via high-security access. Access to the HSMs is not possibledirectly. The only way to have a transaction or similar signed with sucha key is to interact via a multiple secured API. The security ismulti-level.

Key policy module 250 optionally applies one or more policies to use ofany given key stored in custody key vault 290 (also referred to hereinas “custody keys”). Policies may be generated by default (e.g., allcustody keys by default require a successful entry of a username orpassword for use), by an administrator, and/or by a user of clientdevice 111. When a user attempts to use a custody key for any givenpurpose, key policy module 250 accesses an entry of key policy database291 that corresponds to the custody key being used and determinestherefrom one or more policies. The policies may include any, all, or acombination of successful entry of a username and/or password,successful biometric verification (e.g., fingerprint scan, retinal scan,voice scan, face scan, etc.), and the like. In an embodiment, key policymodule 250 selectively applies policies. For example, key policy module250 may determine whether a user has satisfied a compliance check (e.g.,earlier in a session, the user was prompted to comply with a policy). Inone example of a compliance check, key policy module 250 may receivemetadata of the transaction such as the purpose of a transaction. Keypolicy module 250 may then check the metadata against compliance rulessuch as Know Your Transactions (KYT) or Anti-Money Laundering (AML)compliance rules. In one non-limiting example, key policy module 250 maygrant access to a key in the custody key vault 209 only after acompliance policy has been satisfied. Key policy module 250 may makekeys guarded by policies that have not yet been complied withinaccessible to a user. In an embodiment, key policy module 250 may makeit impossible to use custody keys without satisfying a compliance checkof the policy or policies that apply to those keys. In such scenarios,signatures are prevented from being created to execute a transactionuntil compliance is verified.

FIG. 3 depicts a multisignature contract where keys are obtained fromtwo or more sources. In some embodiments, addresses of the keys areprovided to multisig contract 300 (e.g., in place of the keysthemselves). For example, addresses of public keys may be provided tomultisig contract 300. Multisig contract 300 has transactions that arerequested by a user verified by using public keys or addresses of thepublic keys that satisfy the requisite roles. For example, multisigcontract 300 may verify that the received address of a public key of akeypair (e.g., public and private keys) matches the recorded address ofthe public key that was previously assigned a particular role.Additionally, or alternatively, multisig contract 300 may verify areceived transaction by using the recorded address of the public keythat was previously assigned a particular role to verify a signaturegenerated over the transaction, where the signature is allegedlygenerated using a private key corresponding to the public key. Anysuitable signature verification technique may be used, such as asignature verification technique corresponding to a key generationtechnique used to generate the public key and the corresponding privatekey. The private keys may be located on one or more of the user'sdevices, such as user devices 310 and 320, which hold keys 301 and 302,respectively. The same transaction may also need to be signed off by oneor more custody keys 303, 304, and 305, depending on the roles of thosecustody keys and the roles required by multisig contract 300. Contracts140 and 300 may be the same contract or different implementations of amultisignature contract.

Multisig contract 300 may be associated with any number of keys, where asubset are initiation keys and/or approval keys. For example, amultisignature contract may have seven keys, where two of those sevenkeys are initiation keys, and five of those keys are approval keys,where at least two of the approval keys must sign a transactioninitiated by an initiation key for the transaction to process. Forinstance, a single initiation key may be used to initiate a transaction,and a requisite number of approval keys may be required to sign thetransaction in order for the transaction to be executed. An exemplaryapproval key process is discussed below with respect to FIG. 4.

A daily limit may be included in the multisig contract 300, which allowsa user to sign a transaction with one key only (e.g., an initiationkey), rather than a requisite number of threshold keys (e.g., initiationand/or approval keys), up to a number of times equal to the daily limit.From that point forward, the requisite number of keys would be requiredto execute the transaction. The term daily is exemplary, and this limitmay apply to any length of time. The daily limit may be input into theuser interface of the multisig wallet application by the user and thenassigned to the multisig contract 300. The multisig wallet applicationmay be a software application that is executable by a client device andincludes various software modules for generating a user interface forassigning roles to keys based on a user's customization requests andprocessing requests to sign transactions using the keys. The multisigwallet application may perform functions described herein with referenceto a multisignature wallet (e.g., multisig wallet 410, 510, 610, 710,810, or 910, or recovery wallet 620) or custody provider 130.

With regard to access policies, an access policy may be required inorder for a key to be used to successfully sign a transaction. Theaccess policy may be a conventional access policy. For example, a PIN,password, two-factor authentication, or biometric (e.g., fingerprint,face, iris scans, and the like). Additionally, social access controlpolicies may be established (e.g., ask another user on a domain to grantaccess to a key). Other policies may require a proof of connection to aparticular network such as a given wireless (e.g., WiFi) network, localarea network, or virtual private network, a proof of the user being in agiven location, a usage of a defined SIM card, a use of a particularhardware device (e.g., as proven by MAC address), and the like.

FIG. 4 depicts one embodiment of activity corresponding to an approvalkey process when executing a multisignature contract. An approval keyprocess may be triggered by a user of a client device requestingperformance of the transaction. The user may initiate the transactionusing the aforementioned user interface of a client device (e.g., clientdevice 110). The user interface may be provided via a softwareapplication of a multisignature wallet of multisig wallet 410 executedon the client device. This software application may be referred toherein as a “multisignature wallet application.” To initiate thetransaction, the user requests that the transaction 470 be signed usingan initiation key (e.g., key 411), which may be associated with multisigwallet 410. The multisignature wallet application may perform thesigning using the initiation key. Multisig wallet 410 may be associatedwith various keys. As depicted, initiation keys 411 are associated withmultisig wallet 410. Approval keys 420 are also associated with multisigwallet 410. As discussed above, keys may be assigned multiple roles; key421 is assigned a role as both an initiation key and an approval key andkey 422 is assigned a role of approval key. This is merely exemplary;any roles introduced above, and/or another role, may be assigned to anyof the keys of multisig wallet 410. Keys associated with multisig wallet410 may be stored at a client device 110, at custody key vault 290, orat another storage of the user of client device 110.

Transaction 470 may be processed based on a multisignature contract(e.g., multisig contract 300) requiring that a certain number ofsignatures by approval keys are needed. A smart contract service (e.g.,smart contract 140) or a blockchain service (e.g., blockchain 141) mayperform this processing. As depicted, two approval keys are needed,though any number may be substituted for two. Should the requisitenumber of approval keys sign (e.g., as depicted, approval keys 421 and422), then transaction 470 will be executed. The requisite number ofkeys may be determined by referencing smart contract 140, whichindicates the requirements for approval of the multisignature contract,including, for example, the requisite signatures by requisite roles fora transaction to process.

FIG. 5 depicts one embodiment of a veto process for canceling executionof a transaction of a multisignature contract. FIG. 5 depicts multisigwallet 510 of a user (e.g., a user of client device 110). Multisigwallet 510 may include various keys. As depicted, one or more keyshaving a role of an initiation key (e.g., keys 511, 521) are included inmultisig wallet 510. Approval keys 520 may also a part of multisigwallet 510, though they are not depicted. As discussed above, keys maybe assigned multiple roles; key 521 is assigned a role of both anapproval key and a veto key and key 522 is assigned a role of a vetokey. This is merely exemplary; any roles introduced above may beassigned to any of the keys of multisig wallet 510. Keys in multisigwallet 510 may be stored at a client device 110, at custody key vault290, at another storage of the user of client device 110.

As depicted in FIG. 5, key 511 may be used to initiate transaction 570by signing the transaction (e.g., based on a user of a client device,such as client device 110, requesting through the user interface thatthe transaction be executed). A multisig wallet application may sign thetransaction using key 511. This triggers a countdown of an interval oftime, the time being associated with transaction 570, where transaction570 may be canceled. The interval of time may be defined by the user(e.g., based on configuration input using the user interface). In orderto cancel the transaction, a key with a veto role (e.g., key 521 or key522) can sign transaction 570 within the length of time, which in turncauses transaction 570 to be canceled. If no key with a veto role signstransaction 570 during the length of time, then transaction 570 isexecuted (e.g., by blockchain 141). The initiation of the transactionand/or a veto may be communicated using the aforementioned API of themultisignature wallet.

FIG. 6 illustrates one embodiment of activity of using a recoveryprocess to challenge a key with an end goal of replacing the challengedkey with a different key or removing the challenged key. In the processof FIG. 6, any key may be challenged (e.g., an initiation key or anapproval key). For instance, a challenge may be performed where there isno key constellation left that can execute a transaction. Exemplaryscenarios of this sort may include scenarios where there is oneinitiation key, two approval keys, where two signatures are needed tosign a transaction and an initiation key is lost, or both approval keysare lost. Other scenarios are in the scope of this disclosure.

As depicted in FIG. 6, a user may start a challenge, e.g., by requestingthe challenge using a user interface of a client device or invoking acustodian recovery functionality of custody provider 130. The challenge,when requested, causes a recovery key (e.g., key 621 or key 622 ofrecovery wallet 620) to sign a transaction (e.g., 670) that starts arecovery challenge function of the relevant smart contract or a key ofthe relevant smart contract. Multisig wallet 610 is associated with oneor more keys (e.g., initiation keys 611, approval keys 612) that may bechallenged.

The user of client device 111 may have access permissions to recoverykey 622. A system (e.g., multisig wallet application located at a clientdevice or custody provider 130) detects that recovery key 622 hasstarted the challenge function, responsively initiates a challengetransaction, and challenges the key (e.g., key 611 is challenged). Thechallenge transaction initiates the beginning of a length of time,during which the challenged key may sign a transaction sent to stop thechallenge (e.g., by calling a stop challenge function of the relevantsmart contract). Responsive to detecting that the period of time haslapsed without the challenged key signing the transaction, a recoveryactivity 680 is performed. Recovery activity 680 may include replacementor removal of the challenged key (e.g., by assigning the role of thechallenged key to the challenging key or a different key). Responsive todetecting that the challenged key signed a transaction calling the stopchallenge method the challenge is stopped 690.

In some embodiments, recovery wallet 620 prepares a challengetransaction and uses recover key 621 or 622 to sign that transaction.The transaction is then sent to the smart contract within theblockchain. If the transaction is successfully verified using the publickey or the address of the public key corresponding to the recovery key,the smart contract replaces the challenged key (e.g., after a waitingperiod).

In some scenarios, the period for recovery may be very long (e.g., 6months or one year), and it may be unacceptable to have to wait such along period of time to recover an account. For example, where the userof client device 111 loses client device 111, and a key desired for useby the user was only stored at that client device 111, then the user mayhave to wait a year to recover using a recovery key stored at adifferent client device (e.g., client device 110). To reduce theprobability of such an outcome, the user may apply other keys to reducethe recovery time (e.g., using the aforementioned API of the multisigwallet application). To this end, the system may detect that a challengeis signed by other keys of the user (e.g., other recovery and/orapproval keys), thus proving that the user is in possession of thoseother keys. Responsive to detecting such a signature, the length of timemay be reduced (e.g., from six months to one month, and then from onemonth to two days). The amount of time reduced may be default or may beprogrammed by the user in connection with setting up a recovery key. Thereduction of time may increase based on a number of successfulsignatures to the recovery challenge by the user. In some embodiments, asmart contract checks a received signature, which is allegedly generatedusing the challenged key or other keys previously assigned to roles bythe user, by using the public keys or address(es) of the challenged keyor the other keys to verify the signature (e.g., using a cryptographicsignature verification technique corresponding to the cryptographic keygeneration technique used to generate the challenged key or the otherkeys). In some embodiments, a public address may be used to look up(e.g., from the blockchain) or otherwise determine a correspondingpublic key, and the public key may be used for signature verification.Additionally, or alternatively, the public address may be used directlyfor signature verification. In this way, the smart contract candetermine if the signature is valid and reduce the length of timeaccordingly.

In an example embodiment, a “dead man” switch is implemented as aparticular form of the recovery process. For example, if a user (e.g.,owner) of multisig wallet 610 passed away or is incapacitated, usingconventional systems, other users, like a surviving spouse, may wish toaccess and use the keys of multisig wallet 610, but may be unable to doso because there is no mechanism to challenge the incapacitated owner'srights. To guard against such a scenario, recovery key 622 may beprogrammed to challenge, e.g., all keys connected to multisig wallet610. If more than one key is to be challenged, this may be performedusing two independent challenges. Recovery key 622 may be configured toauthorize particular users to challenge the threshold (initiation and/orapproval) keys 611—for example, the original owner of multisig wallet610 may authorize a spouse or family member to challenge the thresholdkeys 611. After the challenge succeeds against all of threshold keys611, recovery key 622 is the only key remaining that is able to controlmultisig wallet 610 by replacing threshold keys 611, thus establishingthe challenging user as the new owner of multisig wallet 610. The ownerof recovery key 622 at this time is able to replace threshold keys 611with newly added threshold keys to multisig wallet 610 to bolster thesecurity of multisig wallet 610 with threshold keys of the new owner'sown design.

Privacy Service

Privacy is an important issue when dealing with crypto currencies. Whileblockchain transactions offer anonymity, certain information oftransacting users may nonetheless be revealed. For example, when a userreceives or executes a payment, an address of the user is known (eventhough the user's exact identity is unknown), from which a balance ofthe user's account identified by that particular address, and allincoming and outgoing transactions of the account, can be determined.

In some embodiments, to improve privacy, a new address may be used foreach transaction, where a user's wallet manages private keyscorresponding to the new addresses, and accumulates account balances. Tomanage account balances given the use of myriad new addresses, thebalances may be balanced offchain, where consistency of an offchainledger may be proven through zero knowledge proofs on the blockchain.However, such embodiments are difficult to use and still satisfycompliance requirements for money laundering prevention. Moreover,privately held assets cannot be used directly in applications where anaccount is required, such as investment in an initial coin offering(ICO), participation in a decentralized autonomous organization (DAO),use of decentralized finance (DeFi), etc., and thus the offchainsolution is not suitable for use in such scenarios.

To ensure complete privacy of a user who makes blockchain transactions,a privacy service may be used. FIG. 7 depicts one embodiment of anexemplary process for using a privacy service and a proxy wallet toexecute private transactions. The process depicted in FIG. 7 is based ona user having a separate account for each application (e.g., gamingapplication, social media application, navigation application, airlinereservation application, etc.), thus separating all applications fromeach other. As long as it is ensured that there is no recognizableconnection between the accounts, complete privacy of the user isensured. By using a different address for each receiver or use case, theprivacy service helps disconnect those addresses from the user andreduces a likelihood that an attacker can discover an address of auser's possessions (e.g., their multisignature wallet). Accordingly, theprivacy service increases the security of a user's multisignature walletsince attackers cannot determine an address from which to begin theirattacks.

FIG. 7 includes multisig wallet 710, privacy service 720, proxy wallet730, blockchain 740, and receiver address 750. Multisig wallet 710operates consistent with multisig wallets as described above. Multisigwallet 710 may be associated with various keys with various roles (e.g.,transaction key, approval key, recovery key, as described above).Additionally, multisig wallet 710 may be associated with one or moreuser proxy keys. The term “user proxy key” or “proxy key,” as usedherein, may refer to an initiation key for a proxy wallet. This key,separate for each proxy wallet, is owned exclusively by the user incontrol of multisig wallet 710.

Although FIGS. 7-9 depict the user proxy key as associated with amultisig wallet and the privacy service key as being associated with aprivacy service (i.e., both separate from the proxy wallet), in someembodiments, the user proxy key and the privacy service key may beassociated with the proxy wallet. In some embodiments, a proxy wallet isa multisignature wallet having two keys: a proxy key and a privacyservice key. In response to a transaction being signed (e.g., by theproxy wallet) by signatures of both keys, the transaction may beprocessed (e.g., by a blockchain).

The term proxy wallet, as used herein, may refer to a multisig walletused as a proxy for a given category of transactions. Assets areseparated into different categories for management by the proxy wallet,rather than by a multisig wallet. The individual proxy wallets can thenbe used separately for different applications (e.g., gaming application,social media application, navigation application, airline reservationapplication, etc.). Proxy wallets each have an associated initiationkey, which may be the user proxy key managed by multisig wallet 810.Privacy is guaranteed by using a proxy wallet for this purpose so longas the association between the proxy wallet and its correspondingmultisig wallet is kept secret. In this way, the connection to themultisig is not disclosed notwithstanding the multisig being used toinitiate block chain transactions.

Privacy service 720 is a service through which transactions areexecuted, but which at no time has control over the assets in the proxywallet. A transaction is initiated in any manner described above, wherethe transaction receives the required signature(s) generated usingthreshold key(s) of multisig wallet 710. However, instead of sending thetransaction to the block chain (e.g., block chain 141), the transactionis sent to privacy service 720. Moreover, the transaction from multisigwallet 710 is signed by the proxy key, in addition to the one or morethreshold keys. Privacy service 720 checks the signatures and thevalidity of the transaction (e.g., that all rules of the multisig smartcontract are fulfilled, compliance is satisfied, policies are satisfied,and so on consistent with the foregoing).

In response to privacy service 720 determining that the transaction isvalid, privacy service 720 signs the transaction using a privacy servicekey, which may be an approval key of the proxy wallet 730. Privacyservice 720 then forwards the transaction to proxy wallet 730, where theappropriate proxy wallet 730 is determined based on the user proxy keyused to sign the transaction by multisig wallet 710. For instance, whenmultisig wallet 710 sends the transaction to privacy service 720,multisig wallet 710 may indicate a public address of the user proxy key,so that privacy service 720 may use the public address to identify theappropriate proxy wallet 730. Additionally, or alternatively, privacyservice 720 may use a number of public addresses to separately verifythe signature generated using the user proxy key. For instance, a publicaddress may be used to look up (e.g., from the blockchain) or otherwisedetermine a corresponding public key, and the public key may be used forsignature verification, and/or the public address may be used directlyfor signature verification. If one of the public addresses leads tosuccessful signature verification, that public address may be used toidentify the appropriate proxy wallet 730. In some embodiments, theappropriate proxy wallet 730 is determined based on both the user proxykey and the privacy service key (e.g., an approval key) used by privacyservice 820. In this way, the connection between multisig wallet 710 andproxy wallet 730 remains secret. Requiring a signature by a user proxykey of multisig wallet 710 ensures that privacy service 720 cannotinitiate a transaction on its own or modify a transaction sent bymultisig wallet 710 and forwarded via the privacy service 720. Aftersignature, the transaction is validated by blockchain 740 (which may beany blockchain 141), and the assets are transferred using receiveraddress 750.

In another example of fulfilling a transaction using proxy wallet 730,the privacy service 720 receives a transaction signed by multisig wallet710 (e.g., signed by a key of multisig wallet 710), where multisigwallet 710 identifies the address corresponding to the user proxy key.The privacy service 720 uses the address of the user proxy key to verifythe signature of the user proxy key and determine which privacy servicekey to use. In determining which privacy service key to use, the privacyservice 720 also determines which proxy wallet to forward thetransaction. Because a proxy wallet can be associated with a user proxykey and a privacy service key, the privacy service 720 can determine theprivacy service key and proxy wallet with the address of the user proxykey.

Privacy service 720, while offering privacy, may, without safeguards, becompromised and cause loss of user control of accounts. For example,privacy service 720 may be hacked, may suffer a power outage, and so on.Embodiments are proposed herein to ensure user control of their accountsin such scenarios. Privacy service 720 is configured to be unable toinitiate a transaction on its own; transactions must be initiated bymultisig wallet 710, thus ensuring that if privacy service 720 ishacked, the malicious party cannot initiate transactions on behalf of auser of the privacy service. Additional or alternative security measuresmay be used to ensure the safety and self-sovereignty of an owner ofmultisig wallet 710 who chooses to use privacy service 720. In anembodiment, a recovery key of multisig wallet 710 may be used toexchange the proxy key. The recovery key, which can also be located inproxy wallet 730, can function similarly to recovery keys 621 or 622 ofFIG. 2. The proxy wallet allows a user to recover a key withoutrevealing the connection between a challenge transaction used torecovery the key and the user's multisig wallet. In some embodiments, ahashed connection to the multisig wallet may be used as an additionalfailsafe. This hashed connection is further described in the descriptionof FIG. 8. Such a recovery key protects the user from a scenario whereprivacy service 720 becomes unavailable or compromised, or where theuser proxy key is lost. The recovery key may be derived from a recoverykey of the multisig wallet 710 using key derivation.

Another security measure may include use of a salted hash. FIG. 8depicts an exemplary process for executing a transaction with a proxywallet using a salted hash. The salted hash is a last resort mechanismfor a user to take control of multisig wallet 810 by giving up theuser's privacy. FIG. 8 includes multisig wallet 810, privacy service820, proxy wallet 830, blockchain 840, and receiver address 850, each ofthese having like numbering to similar features shown in FIG. 7, andeach of which carry the same weight of description of their counterpartsdescribed with reference to FIG. 7.

As shown, privacy service 820 is disabled or compromised, and thusmultisig wallet 810 directly accesses proxy wallet 830 to perform atransaction. For this purpose, a salted hash is stored in proxy wallet830. This hash can only be created using the address of multisig wallet810, the address of proxy wallet 830, and the “salt” (that is, anadditional secret such as random data that may be used as an additionalinput to a hash function). With the “salt” it is ensured that theinformation of proxy wallet 830 does not allow any conclusion aboutmultisig wallet 810 and its keys. In this way, no other user is able toreproduce the hash even if that user knows the public address frommultisig wallet 810. However, as soon as a transaction is executed usingmultisig wallet 810, a connection between multisig wallet 810 and proxywallet 830 is established, which means that privacy is lost. Thisensures that even if the privacy service fails or is corrupted and theuser proxy key and recovery key are lost, multisig wallet 810 retainscontrol of the proxy wallet 830 and therefore the assets. That is, themultisig wallet 810 can sign a transaction using a transaction key(e.g., an initiation key, approval key, recovery key, or any othersuitable customizable role for a key) and create the salted hash becausethe user knows the additional secret, and with this, the multisig wallet810 can prove that the user is the owner of proxy wallet 830, thusensuring that the user can recover proxy wallet 830, with the onlyconsequence being a loss of privacy. This ensures that the user canalways recover their assets from proxy wallet 830 even if privacyservice 820 is compromised.

In an embodiment, a further optimization can be made by replacing theprivacy service key and the user proxy key with a multiparty computationsignature (MPC). FIG. 9 depicts an exemplary process for executing atransaction with a proxy wallet using a multiparty computationsignature. FIG. 9 includes multisig wallet 910, privacy service 920,proxy wallet 930, blockchain 940, and receiver address 950, each ofthese having like numbering to similar features shown in FIG. 7, andeach of which carry the same weight of description of their counterpartsdescribed with reference to FIG. 7. In this embodiment, the user (e.g.,at their client device) and privacy service 920 each have an MPCkeyshare, so that both the user and the privacy service 920 have toparticipate to generate the required signature. Neither, acting alone,is able to do so. Because the keyshares can be exchanged withoutchanging the public key, key (share) rotation is possible withoutchanging the state of the proxy wallet contract (i.e. without executinga transaction on the block chain). The keys may be rotated to improvethe security because a potentially leaked or stolen keyshare would beonly valid until the next rotation, giving an attacker only a short timeto accessed a user's secured possessions.

Example Processes for Transactions Using Customized Keys or a PrivacyService

FIG. 10 is a flowchart illustrating process 1000 for initiating atransaction using a customized key, in accordance with one embodiment. Amultisignature wallet application may perform process 1000. In someembodiments, the multisignature wallet application performs operationsof process 1000 in parallel or in different orders, or may performdifferent steps.

The multisignature wallet application receives 1001 a command to assigna role to a key. The multisignature wallet application may output agraphical user interface (GUI) including UI elements for user input thatenables the multisignature wallet application to receive 1001 a commandto assign a role to a key. For example, a user may use a GUI generatedby a multisig application on a client device to request two approvalkeys for a transaction to be processed by a smart contract or ablockchain. The user interface can be output by a device of a custodyprovider. The key, for which a command was received 1001 for a role tobe assigned, can be stored by the custody provider. The role associatedwith the key can be at least one of a recovery function, approvalfunction, or initiation function.

In some embodiments, the role corresponds to a recovery function and thetransaction is a challenge transaction of a first key for replacement bya second key. The first key can be replaced (e.g., by a smart contract)based on a monitoring, during a length of time, for a message signedusing the first key. A multisignature wallet application may alsoperform the monitoring by looking out for transactions signed with thefirst key. Upon detecting a signature by the first key during the lengthof time, the challenge transaction can be canceled. Alternatively, upondetermining that the length of time has elapsed without detecting thesignature, the first key can be replaced with the second key. The lengthof time can also be reduced upon one or more additional keys signing thechallenge transaction. The public addresses of the one or more keys canbe associated with the smart contract so that the smart contract canverify the validity of the signatures as belonging to the proper user oruser's multisignature wallet (i.e., the user whose keys are beingchallenged). The amount of time can vary based on which of the one ormore additional keys is detected.

The multisignature wallet application transmits 1002 an update to asmart contract to associate the role with the key. In some embodiments,in response to receiving 1001 the command, the multisignature walletapplication may transmit an update to a smart contract to associate therole with the key. For example, for two approval keys requested by auser, the multisignature wallet application transmits 1002 an updatespecifying the two requested approval key roles. An update may include apublic key or an address of the public key of a keypair and auser-specified role to be associated with the keypair by the smartcontract. The key may be associated with a multisignature wallet. Forexample, the user requesting the two approval keys may have amultisignature wallet with existing approval keys, and the smartcontract will associate two new key addresses with the two newlyrequested approval keys.

The multisignature wallet application receives 1003 a request toinitiate a transaction. For example, the user may sign a transactionusing an initiation key of their multisignature wallet to request toinitiate the transaction. In another example, a user signs a challengetransaction using a recovery key of their multisignature wallet torequest that a previously assigned key (e.g., an initiation key of auser who can no longer access their multisignature wallet) in anotheruser's multisignature wallet be replaced with a new key (e.g., a newinitiation key). The transaction is affected based on whether a givenkey having the role signs the transaction. For example, the transactionmay be initiate unless signed by the initiation key, or the initiatedtransaction signed by the initiation key may not be approved unlesssigned by an approval key. In another example, a challenge transactionmay be unsuccessful if the challenged key signs the challengetransaction, or the challenge transaction may be successful if thechallenged key fails to sign the challenge transaction a particularperiod of time (e.g., six months) after the recovery key signs thechallenge transaction. In response to the key assigned with the rolesigning the transaction, the transaction can be affected in acorresponding manner. For example, in response to an approval keysigning a transaction, the transaction can be processed by a blockchain.

The multisignature wallet application receives 1004 an indication ofwhether the transaction is affected in a manner corresponding to therole. In one example, the multisignature wallet application receives aconfirmation that a transaction signed by an approval key has beenexecuted by a blockchain. In another example, the multisignature walletapplication receives a confirmation that a challenge transaction wasblocked in response to the smart contract receiving a signature of thechallenge transaction using a key of a user whose key(s) were beingchallenged.

FIG. 11 is a flowchart illustrating process 1100 for initiating ablockchain transaction using a privacy service, in accordance with oneembodiment. A privacy service as described herein (e.g., privacyservices 720, 820, or 920) may perform process 1100. In someembodiments, the privacy service performs operations of process 1100 inparallel or in different orders, or may perform different steps.

The privacy service receives 1101 a blockchain transaction signed by aproxy key of a multisignature wallet. For example, a multisignaturewallet initiates a transaction by using an initiation key or an addressof the key to sign the transaction. The privacy service identifies 1102a proxy wallet. The privacy service may identify 1102 the proxy walletusing the signature of the transaction. For example, a proxy wallet maybe associated with a pair of keys: the proxy key and a privacy servicekey, each having corresponding addresses. Using the address of the proxykey, the privacy service identifies 1102 the proxy wallet associatedwith the corresponding proxy key. The privacy service validates 1103 theblockchain transaction. For example, the privacy service verifies thatall rules of a multisignature smart contract are fulfilled. The privacyservice signs 1104 the blockchain transaction. The privacy service cansign 1104 the blockchain transaction using a key of the proxy wallet.For example, the privacy service may sign using the privacy service keyor use both the proxy key and the privacy service key to generate an MPCto sign the transaction. The privacy service sends 1105 the signedblockchain transaction to the proxy wallet. In this way, a signature byone or more keys of the proxy wallet can cause a transaction to beexecuted. Alternatively, a multisignature wallet can sign 1104 theblockchain transaction key using a salted hash generated using anaddress of the proxy wallet, an address of the multisignature wallet,and a salt. The multisignature wallet can send 1105 the signedblockchain transaction to the proxy wallet. The privacy service receives1106 an indication of whether the blockchain transaction was executed.For example, the proxy wallet may receive a confirmation that theblockchain transaction was executed after the proxy wallet sends thetransaction to a blockchain (e.g., blockchain 740, 840, or 940), and theproxy wallet may provide the confirmation to the privacy service inturn.

The privacy service key can be an approval key of the proxy wallet.Validating the blockchain transaction can include determining that thetransaction conforms to a compliance protocol. The proxy key can be aninitiation key of the proxy wallet. In some embodiments, signing theblockchain transaction using the proxy wallet includes signing theblockchain transaction using a key of the proxy wallet.

FIG. 12 is a flowchart illustrating process 1200 for initiating atransaction using a smart contract, in accordance with one embodiment. Asmart contract or blockchain on which a smart contract runs may performthe process 1200. In some embodiments, the smart contract performsoperations of process 1200 in parallel or in different orders, or mayperform different steps. The smart contract receives 1201 an update froma multisignature wallet to associate a role with a key. The key can beassociated with the multisignature wallet (e.g., a key of the wallet).The smart contract receives 1202 a transaction signed using a given key.The smart contract determines 1203 whether the given key is associatedwith the role associated with the key (e.g., determining if the publicaddress of the given key matches the public address of the key indicatedthrough the received 1201 update). If the key is associated with therole, the smart contract may transmit 1204 an indication to themultisignature wallet that the signed transaction is affected in amanner corresponding to the role of the key (e.g., a signed challengetransaction is affected by initiating a countdown timer for a challengeduser's keys to sign and block the challenge transaction or a transactionsigned by an approval key is forwarded to a blockchain for processingafter determining the approval key has a public address that matches anaddress of record on the smart contract). In some embodiments, the smartcontract may provide the signed transaction to a blockchain forprocessing in addition or alternative to transmitting 1204 theindication to the multisignature wallet. Although the smart contract isshown in FIG. 12 as transmitting 1204 the indication, the smart contractmay not provide an indication in response to determining the key isassociated with the role. If the key is not associated with the role,the smart contract may return to receiving 1202 a transaction signedusing a given key.

In some embodiments, the role corresponds to a recovery function,wherein the transaction is a challenge transaction of one key forreplacement by another key. The smart contract can replace the key inresponse to receiving a notification from the multisignature walletthat, during a length of time, a message was signed using the key andthat in response to the message being signed, the challenge transactionwas blocked by the multisignature wallet. The smart contract canreplace, upon to determining that the length of time has elapsed withoutthe message being signed, the key with the other key. In someembodiments, the smart contract can determine 1203 whether the secondkey is associated with the role associated with the first key bydetermining whether a public address of the second key is the same as apublic address of the first key.

Computing Machine Architecture

FIG. 13 is a block diagram illustrating components of an example machineable to read instructions from a machine-readable medium and executethem in a processor (or controller). Specifically, FIG. 13 shows adiagrammatic representation of a machine in the example form of acomputer system 1300 within which program code (e.g., software) forcausing the machine to perform any one or more of the methodologiesdiscussed herein may be executed. In some of the describedconfigurations, the methodologies were described via functionalconfigurations of the modules. The modules may be comprised of programcode that itself may be comprised of one or more instructions 1324 thatmay be stored in a non-transitory computer readable storage medium andmay be executable by one or more processors 1302. In alternativeembodiments, the machine operates as a standalone device or may beconnected (e.g., networked) to other machines. In a networkeddeployment, the machine may operate in the capacity of a server machineor a client machine in a server-client network environment, or as a peermachine in a peer-to-peer (or distributed) network environment.

The machine may be a server computer, a client computer, a personalcomputer (PC), a tablet PC, a set-top box (STB), a personal digitalassistant (PDA), a cellular telephone, a smartphone, a web appliance, anetwork router, switch or bridge, or any machine capable of executinginstructions 1324 (sequential or otherwise) that specify actions to betaken by that machine. Further, while only a single machine isillustrated, the term “machine” shall also be taken to include anycollection of machines that individually or jointly execute instructions1324 to perform any one or more of the methodologies discussed herein.

The example computer system 1300 includes a processor 1302 (e.g., acentral processing unit (CPU), a graphics processing unit (GPU), adigital signal processor (DSP), one or more application specificintegrated circuits (ASICs), one or more radio-frequency integratedcircuits (RFICs), or any combination of these), a main memory 1304, anda static memory 1306, which are configured to communicate with eachother via a bus 1308. The computer system 1300 may further includevisual display interface 1310. The visual interface may include asoftware driver that enables displaying user interfaces on a screen (ordisplay). The visual interface may display user interfaces directly(e.g., on the screen) or indirectly on a surface, window, or the like(e.g., via a visual projection unit). For ease of discussion the visualinterface may be described as a screen. The visual interface 1310 mayinclude or may interface with a touch enabled screen. The computersystem 1300 may also include alphanumeric input device 1312 (e.g., akeyboard or touch screen keyboard), a cursor control device 1314 (e.g.,a mouse, a trackball, a joystick, a motion sensor, or other pointinginstrument), a storage unit 1316, a signal generation device 1318 (e.g.,a speaker), and a network interface device 1320, which also areconfigured to communicate via the bus 1308.

The storage unit 1316 includes a machine-readable medium 1322 on whichis stored instructions 1324 (e.g., software) embodying any one or moreof the methodologies or functions described herein. The instructions1324 (e.g., software) may also reside, completely or at least partially,within the main memory 1304 or within the processor 1302 (e.g., within aprocessor's cache memory) during execution thereof by the computersystem 1300, the main memory 1304 and the processor 1302 alsoconstituting machine-readable media. The instructions 1324 (e.g.,software) may be transmitted or received over a network 1326 via thenetwork interface device 1320.

While machine-readable medium 1322 is shown in an example embodiment tobe a single medium, the term “machine-readable medium” should be takento include a single medium or multiple media (e.g., a centralized ordistributed database, or associated caches and servers) able to storeinstructions (e.g., instructions 1324). The term “machine-readablemedium” shall also be taken to include any medium that is capable ofstoring instructions (e.g., instructions 1324) for execution by themachine and that cause the machine to perform any one or more of themethodologies disclosed herein. The term “machine-readable medium”includes, but not be limited to, data repositories in the form ofsolid-state memories, optical media, and magnetic media.

Additional Configuration Considerations

The systems and methods disclosed herein offer advantages in securityand integrity of blockchain keys. Customization of keys enables users toconfigure security on their keys as desired. Smart contract storage ofthe right of keys enables keys to be securely stored by a custodyprovider while ensuring that the rights of those keys are decentralized,transparent, and recoverable and to enforce these rights on blockchainlevel. Recovery keys enable users to avoid a single chain of failure,such as their death or incapacitation, or theft or loss of devices, fromcausing funds to be irretrievably lost or accessed without additionalauthorization.

Throughout this specification, plural instances may implementcomponents, operations, or structures described as a single instance.Although individual operations of one or more methods are illustratedand described as separate operations, one or more of the individualoperations may be performed concurrently, and nothing requires that theoperations be performed in the order illustrated. Structures andfunctionality presented as separate components in example configurationsmay be implemented as a combined structure or component. Similarly,structures and functionality presented as a single component may beimplemented as separate components. These and other variations,modifications, additions, and improvements fall within the scope of thesubject matter herein.

Certain embodiments are described herein as including logic or a numberof components, modules, or mechanisms. Modules may constitute eithersoftware modules (e.g., code embodied on a machine-readable medium or ina transmission signal) or hardware modules. A hardware module istangible unit capable of performing certain operations and may beconfigured or arranged in a certain manner. In example embodiments, oneor more computer systems (e.g., a standalone, client or server computersystem and/or a distributed peer-to-peer network) or one or morehardware modules of a computer system (e.g., a processor or a group ofprocessors) may be configured by software (e.g., an application orapplication portion) as a hardware module that operates to performcertain operations as described herein.

In various embodiments, a hardware module may be implementedmechanically or electronically. For example, a hardware module maycomprise dedicated circuitry or logic that is permanently configured(e.g., as a special-purpose processor, such as a field programmable gatearray (FPGA) or an application-specific integrated circuit (ASIC)) toperform certain operations. A hardware module may also compriseprogrammable logic or circuitry (e.g., as encompassed within ageneral-purpose processor or other programmable processor) that istemporarily configured by software to perform certain operations. Itwill be appreciated that the decision to implement a hardware modulemechanically, in dedicated and permanently configured circuitry, or intemporarily configured circuitry (e.g., configured by software) may bedriven by cost and time considerations.

Accordingly, the term “hardware module” should be understood toencompass a tangible entity, be that an entity that is physicallyconstructed, permanently configured (e.g., hardwired), or temporarilyconfigured (e.g., programmed) to operate in a certain manner or toperform certain operations described herein. As used herein,“hardware-implemented module” refers to a hardware module. Consideringembodiments in which hardware modules are temporarily configured (e.g.,programmed), each of the hardware modules need not be configured orinstantiated at any one instance in time. For example, where thehardware modules comprise a general-purpose processor configured usingsoftware, the general-purpose processor may be configured as respectivedifferent hardware modules at different times. Software may accordinglyconfigure a processor, for example, to constitute a particular hardwaremodule at one instance of time and to constitute a different hardwaremodule at a different instance of time.

Hardware modules can provide information to, and receive informationfrom, other hardware modules. Accordingly, the described hardwaremodules may be regarded as being communicatively coupled. Where multipleof such hardware modules exist contemporaneously, communications may beachieved through signal transmission (e.g., over appropriate circuitsand buses) that connect the hardware modules. In embodiments in whichmultiple hardware modules are configured or instantiated at differenttimes, communications between such hardware modules may be achieved, forexample, through the storage and retrieval of information in memorystructures to which the multiple hardware modules have access. Forexample, one hardware module may perform an operation and store theoutput of that operation in a memory device to which it iscommunicatively coupled. A further hardware module may then, at a latertime, access the memory device to retrieve and process the storedoutput. Hardware modules may also initiate communications with input oroutput devices, and can operate on a resource (e.g., a collection ofinformation).

The various operations of example methods described herein may beperformed, at least partially, by one or more processors that aretemporarily configured (e.g., by software) or permanently configured toperform the relevant operations. Whether temporarily or permanentlyconfigured, such processors may constitute processor-implemented modulesthat operate to perform one or more operations or functions. The modulesreferred to herein may, in some example embodiments, compriseprocessor-implemented modules.

Similarly, the methods described herein may be at least partiallyprocessor-implemented. For example, at least some of the operations of amethod may be performed by one or processors or processor-implementedhardware modules. The performance of certain of the operations may bedistributed among the one or more processors, not only residing within asingle machine, but deployed across a number of machines. In someexample embodiments, the processor or processors may be located in asingle location (e.g., within a home environment, an office environmentor as a server farm), while in other embodiments the processors may bedistributed across a number of locations.

The one or more processors may also operate to support performance ofthe relevant operations in a “cloud computing” environment or as a“software as a service” (SaaS). For example, at least some of theoperations may be performed by a group of computers (as examples ofmachines including processors), these operations being accessible via anetwork (e.g., the Internet) and via one or more appropriate interfaces(e.g., application program interfaces (APIs).)

The performance of certain of the operations may be distributed amongthe one or more processors, not only residing within a single machine,but deployed across a number of machines. In some example embodiments,the one or more processors or processor-implemented modules may belocated in a single geographic location (e.g., within a homeenvironment, an office environment, or a server farm). In other exampleembodiments, the one or more processors or processor-implemented modulesmay be distributed across a number of geographic locations.

Some portions of this specification are presented in terms of algorithmsor symbolic representations of operations on data stored as bits orbinary digital signals within a machine memory (e.g., a computermemory). These algorithms or symbolic representations are examples oftechniques used by those of ordinary skill in the data processing artsto convey the substance of their work to others skilled in the art. Asused herein, an “algorithm” is a self-consistent sequence of operationsor similar processing leading to a desired result. In this context,algorithms and operations involve physical manipulation of physicalquantities. Typically, but not necessarily, such quantities may take theform of electrical, magnetic, or optical signals capable of beingstored, accessed, transferred, combined, compared, or otherwisemanipulated by a machine. It is convenient at times, principally forreasons of common usage, to refer to such signals using words such as“data,” “content,” “bits,” “values,” “elements,” “symbols,”“characters,” “terms,” “numbers,” “numerals,” or the like. These words,however, are merely convenient labels and are to be associated withappropriate physical quantities.

Unless specifically stated otherwise, discussions herein using wordssuch as “processing,” “computing,” “calculating,” “determining,”“presenting,” “displaying,” or the like may refer to actions orprocesses of a machine (e.g., a computer) that manipulates or transformsdata represented as physical (e.g., electronic, magnetic, or optical)quantities within one or more memories (e.g., volatile memory,non-volatile memory, or a combination thereof), registers, or othermachine components that receive, store, transmit, or displayinformation.

As used herein any reference to “one embodiment” or “an embodiment”means that a particular element, feature, structure, or characteristicdescribed in connection with the embodiment is included in at least oneembodiment. The appearances of the phrase “in one embodiment” in variousplaces in the specification are not necessarily all referring to thesame embodiment.

Some embodiments may be described using the expression “coupled” and“connected” along with their derivatives. It should be understood thatthese terms are not intended as synonyms for each other. For example,some embodiments may be described using the term “connected” to indicatethat two or more elements are in direct physical or electrical contactwith each other. In another example, some embodiments may be describedusing the term “coupled” to indicate that two or more elements are indirect physical or electrical contact. The term “coupled,” however, mayalso mean that two or more elements are not in direct contact with eachother, but yet still co-operate or interact with each other. Theembodiments are not limited in this context.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,method, article, or apparatus that comprises a list of elements is notnecessarily limited to only those elements but may include otherelements not expressly listed or inherent to such process, method,article, or apparatus. Further, unless expressly stated to the contrary,“or” refers to an inclusive or and not to an exclusive or. For example,a condition A or B is satisfied by any one of the following: A is true(or present) and B is false (or not present), A is false (or notpresent) and B is true (or present), and both A and B are true (orpresent).

In addition, use of the “a” or “an” are employed to describe elementsand components of the embodiments herein. This is done merely forconvenience and to give a general sense of the invention. Thisdescription should be read to include one or at least one and thesingular also includes the plural unless it is obvious that it is meantotherwise.

Upon reading this disclosure, those of skill in the art will appreciatestill additional alternative structural and functional designs for asystem and a process for a custody provider and customization of keysthrough the disclosed principles herein. Thus, while particularembodiments and applications have been illustrated and described, it isto be understood that the disclosed embodiments are not limited to theprecise construction and components disclosed herein. Variousmodifications, changes and variations, which will be apparent to thoseskilled in the art, may be made in the arrangement, operation anddetails of the method and apparatus disclosed herein without departingfrom the spirit and scope defined in the appended claims.

What is claimed is:
 1. A method comprising: receiving a blockchaintransaction signed by a proxy key of a multisignature wallet;identifying based on the proxy key, a proxy wallet; validating theblockchain transaction; signing, upon validating the blockchaintransaction, the blockchain transaction using the proxy wallet; sending,to the proxy wallet, the blockchain transaction signed using the proxywallet; and receiving, from the proxy wallet, an indication of whetherthe blockchain transaction was executed.
 2. The method of claim 1,wherein signing the blockchain transaction using the proxy walletcomprises signing the blockchain transaction using a key of the proxywallet.
 3. The method of claim 1, wherein the key of the proxy wallet isa privacy service key.
 4. The method of claim 3, wherein signing theblockchain transaction using the privacy service key comprises signingthe blockchain transaction using a combined signature based on theprivacy service key and the proxy key.
 5. The method of claim 4, whereinthe combined signature is a multiparty computation signature.
 6. Themethod of claim 3, wherein the privacy service key is an approval key ofthe proxy wallet.
 7. The method of claim 1, wherein signing theblockchain transaction using the proxy wallet comprises signing theblockchain transaction using a salted hash, and further comprisinggenerating the salted hash using an address of the multisignaturewallet, an address of the proxy wallet, and a salt.
 8. The method ofclaim 1, wherein validating the blockchain transaction comprisesdetermining that the transaction conforms to a compliance protocol. 9.The method of claim 1, wherein the proxy key is an initiation key of theproxy wallet.
 10. A non-transitory computer-readable medium comprisingmemory with instructions encoded thereon, the instructions, whenexecuted, causing at least one processor to: receive a blockchaintransaction signed by a proxy key of a multisignature wallet; identifybased on the proxy key, a proxy wallet; validate the blockchaintransaction; sign, upon validation of the blockchain transaction, theblockchain transaction using the proxy wallet; send, to the proxywallet, the blockchain transaction signed using the proxy wallet; andreceive, from the proxy wallet, an indication of whether the blockchaintransaction was executed.
 11. The non-transitory computer-readablemedium of claim 10, wherein the instructions to sign the blockchaintransaction using the proxy wallet comprises instructions that whenexecuted causes the at least one processor to sign the blockchaintransaction using a key of the proxy wallet.
 12. The non-transitorycomputer-readable medium of claim 10, wherein the key of the proxywallet is a privacy service key.
 13. The non-transitorycomputer-readable medium of claim 12, wherein the instructions to signthe blockchain transaction using the privacy service key comprisesinstructions that when executed causes the at least one processor tosign the blockchain transaction using a combined signature based on theprivacy service key and the proxy key.
 14. The non-transitorycomputer-readable medium of claim 13, wherein the combined signature isa multiparty computation signature.
 15. The non-transitorycomputer-readable medium of claim 12, wherein the privacy service key isan approval key of the proxy wallet.
 16. The non-transitorycomputer-readable medium of claim 10, wherein the instructions to signthe blockchain transaction using the proxy wallet comprises instructionsthat when executed causes the at least one processor to sign theblockchain transaction using a salted hash, and further comprisinginstructions that when executed cause the at least one processor togenerate the salted hash using an address of the multisignature wallet,an address of the proxy wallet, and a salt.
 17. The non-transitorycomputer-readable medium of claim 10, wherein the instructions tovalidate the blockchain transaction comprises instructions that whenexecuted causes the at least one processor to determine that thetransaction conforms to a compliance protocol.
 18. The non-transitorycomputer-readable medium of claim 10, wherein the proxy key is aninitiation key of the proxy wallet.
 19. A system comprising memory withinstructions encoded thereon and one or more processors, when executingthe instructions, that are caused to perform operations comprising:receiving a blockchain transaction signed by a proxy key of amultisignature wallet; identifying based on the proxy key, a proxywallet; validating the blockchain transaction; signing, upon validatingthe blockchain transaction, the blockchain transaction using the proxywallet; and sending, to the proxy wallet, the blockchain transactionsigned using the proxy wallet; and receiving, from the proxy wallet, anindication of whether the blockchain transaction was executed.
 20. Thesystem of claim 19, wherein signing the blockchain transaction using theproxy wallet comprises signing the blockchain transaction using a key ofthe proxy wallet.